home *** CD-ROM | disk | FTP | other *** search
/ ftp.cs.arizona.edu / ftp.cs.arizona.edu.tar / ftp.cs.arizona.edu / icon / newsgrp / group01a.txt / 000008_icon-group-sender _Wed May 17 07:40:50 2000.msg < prev    next >
Internet Message Format  |  2002-01-03  |  6KB
  1. Return-Path: <icon-group-sender>
  2. Received: (from root@localhost)
  3.     by baskerville.CS.Arizona.EDU (8.9.1a/8.9.1) id HAA00658
  4.     for icon-group-addresses; Wed, 17 May 2000 07:40:36 -0700 (MST)
  5. Message-Id: <200005171440.HAA00658@baskerville.CS.Arizona.EDU>
  6. From: "Ian Trudel" <ian.trudel@tr.cgocable.ca>
  7. X-Newsgroups: comp.lang.icon
  8. Subject: Re: Is Anyone Working On A Unicode Version Of Icon?
  9. X-Priority: 3
  10. X-MSMail-Priority: Normal
  11. X-Newsreader: Microsoft Outlook Express 5.00.2919.6600
  12. X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6600
  13. Date: Wed, 17 May 2000 05:26:27 GMT
  14. X-Complaints-To: abuse@cgocable.ca
  15. X-Trace: carnaval.risq.qc.ca 958541187 24.226.208.172 (Wed, 17 May 2000 01:26:27 EDT)
  16. To: icon-group@optima.CS.Arizona.EDU
  17. Errors-To: icon-group-errors@optima.CS.Arizona.EDU
  18. Status: RO
  19. Content-Length: 4795
  20.  
  21. "Marc Espie" <espie@liafa.jussieu.fr> a ∩┐╜crit dans le message news:
  22. 8ft0ri$5ao$1@vishnu.jussieu.fr...
  23. > In article <7xnU4.786$to2.102519@carnaval.risq.qc.ca>,
  24. > Ian Trudel <ian.trudel@tr.cgocable.ca> wrote:
  25. > >Yes, but there are many factors that may not be in favor of doing
  26. primitive
  27. > >types in Icon. Speed issue may be a problem. Or when the primitive uses
  28. > >system depend things, such as sockets or some database API. Yet, the
  29. spirit
  30. > >of Icon is not "everything should be made in Icon" such as Smalltalk
  31. > >communities. Icon is not even bootstrapped. This latter made me
  32. surprised,
  33. > >Icon is so powerful and his text processing feature would just let anyone
  34. > >write good, complete and yet understandable compiler/interpreter!
  35. > I've always been under the impression that the Icon project has a shortage
  36. > of man power, which means that many cool things actually don't exist.
  37.  
  38. Well, yet I just mean things that already exist.. but maybe Icon can help us
  39. to do these in some easier manners?! ::)
  40.  
  41. > Personally, I would love to see Icon extended to be Idol (without the
  42. > preprocessing, which makes things awkward enough to debug for me that I
  43. > seldom use idol), or I would love to see the icon compiler resurrected,
  44. and
  45. > extended to handle separate compilation and direct translation to C
  46. > primitive numeric types (well, C++ looks like a more viable alternative,
  47. > but then I'm weird).
  48.  
  49. My feeling about Idol is: this is just the same as C and Objective-C. Having
  50. Idol implemented in the core of Icon's implementation may not be trivial
  51. task at all. I don't know Idol, but Objective-C allows many dynamic things
  52. that you just couldn't do in C++. If Idol does so, it makes the full C
  53. implementation harder to write. Since I haven't tried Idol, I can't speak
  54. with much concern, but it may just be matter of changing few things out the
  55. current preprocessing implementation to make it stronger. Yet, you could
  56. also build a special debugging tool.
  57.  
  58. I'm some C fellow, but I'm just thinking as an Icon programmer, we should
  59. get out of any direct contact with C. Hence I'm getting interest in some
  60. bootstrapping, writting primitives in Icon (which they would be translated
  61. in C for compilation and linking). If Icon would allow us to write shared
  62. library, that'd really rocks. We could write some high level primitives that
  63. really needs to be written in Icon (only few cases, IMO). Unfortunatly,
  64. handling shared library is often OS-oriented. Under *NIX, it's pretty easy,
  65. but under Windows and OS/2, it requires some special structure. Anyway, this
  66. is just a thought!
  67.  
  68. As you write about C++, I don't see any point of it. Icon is implemented in
  69. C and C is available on a *lot* of platforms and works quite same (I've got
  70. a weird feeling "quite same", "quite same", [..]). You should not forget
  71. that the interface with generated code and Icon would probably be in C
  72. rather than C++ anyway. I think the standard translator should translate
  73. Icon to C, but nothing says there should not be a C++ translator available
  74. as well.
  75.  
  76. BTW, I just like your "icon compiler resurrected" ! It's an interesting
  77. thing that talks by itself. Actually, the current Icon implementation is a
  78. little bit complex. I've seen worst, of course, Icon is nonetheless clearly
  79. written. But since I'm some VM hacker wannabe (*LOL*), I got in touch with
  80. some implementations out there. Smalltalk's VM came up the easiest one.
  81. Squeak in particular is bringing a new vision of VM implementations.
  82. Squeak's VM is pretty easy to understand, even for a newbie VM hacker. I
  83. don't think it should remplace Icon. I'm not promoting Smalltalk here. I
  84. just think it could help to reimplement Icon in a new, fresh, and very
  85. simple manner. For exemple, block contexts in Smalltalk are just the same as
  86. "scanning environment", but they are not specific to strings, not specific
  87. at all! This would be a long term project that IPG would probably not want
  88. to do. However, the dynamic primitive data types would be much more
  89. interesting and smaller project.
  90.  
  91. > Unfortunately, I don't believe that the projet has resources to do that,
  92. > and I also know that I'm tangled up in enough programming projects that
  93. > I can't afford yet another one :(
  94.  
  95. I don't know the position of IPG in the moment, they'll probably hook on our
  96. thread this week. I don't know if I would do it myself, I'm kinda concerned
  97. in professional development and willing to write software(s) in Icon. The
  98. fact is I need something to pay my university fees. ::) Another fact is, if
  99. I would do it.. will IPG integrate it to Icon? If the answer is no, I would
  100. not even write a line of code because this would lead to ANOTHER dialect of
  101. the language. I'd rather support fully Icon.
  102.  
  103. cheer,
  104. --
  105. Ian Trudel, aka BackOrder
  106. StarTrip Server Administrator
  107. http://startrip.gene6.com/
  108.  
  109.  
  110.